I also thought this to be an editor level setting first, but I felt it's not affecting the whole editor and only limited to the sidebar section. Also, I could not find any single place where all the labels are listed as a source of truth. So ended up adding the filter in the component itself.

But if this is useful in wider sense, then taking a generic approach and a single collection of all the labels at one place makes more sense.

My next question would be, which labels are good candidates to be part of this collection? Not everyone would like to customise them. So should it be part of WordPress Core or the Gutenberg plugin itself?

This should be discussed first, what's the best strategy moving forward with adding new filters for UI labels and what naming conventions should be used before we proceed with this particular use case.

@gziolo where is the best place to kick off this discussion? In this PR?, the #core-editor channel, elsewhere?

@aprea @gziolo We could discuss this in tomorrow's core editor meeting on Slack

Reminds me a bit of #12517 by the way :-)

Reminds me a bit of #12517 by the way :-)

Wow, that's wild. I would not have imagined that. 😃

We could discuss this in tomorrow's core editor meeting on Slack

Sure, it sounds like a great topic to discuss.

Reminds me a bit of #12517 by the way :-)

I was thinking about it the other day. It's definitely one of the options as long as we ensure it performs well enough so you don't have to apply the same filters all over again on every component's re-render.

I was also thinking about the alternatives we could investigate. I came up with one idea so far. Introduce useTranslation React hook which you would have to explicitly call with some unique name for the filter to open a given string for modifications. The rationale behind it is, that sometimes you use the same translation string in many places and you don't necessarily want to update all of them at the same time. Having React hook gives us also more flexibility as we could re-render component when a new filter is applied for the translation, even after the page was rendered.

Well, we could also discuss some set of constraints which would make the initial implementation safer if we do something like #12517. Example:

• all filters need to be applied before the initial render
• only translations with context applied can be filterable

Thoughts on this from last Weekly Editor Chat:

@gziolo:

We still would want to use applyFilters, yes
We were concerned in the past about performance implications and now I think that another issues is the discovery of all filterable translations

@youknowriad:

One "somehow related" idea I was thinking about is the fact that applyFilters is very sensitive to the scripts loading order and we have an opportunity to build a useFilter alternative to fix this.

@youknowriad, if I'm to take your approach of introducing new useFilters hook, in which package, would you put that?

If we were to add a useFilter it should probably go in the filters package. I guess this means adding a @wordpress/element dependency to that package but maybe it's ok? Thoughts?

If we were to add a useFilter it should probably go in the filters package. I guess this means adding a @wordpress/element dependency to that package but maybe it's ok? Thoughts?

I was thinking, we might want to place it inside @wordpress/plugins which depends on both @wordpress/element and @wordpress/hooks already.

Oh. A new package of its own?

adding a @wordpress/element dependency

This should be fine, I guess.

But, what qualifies for a new package? What purpose it's going to serve? What else it's going to contain?

@wordpress/plugins

This seems fine. I would not have much of an opinion on this (Lack of knowledge). Would defer to others.

I was actually thinking about the hooks package (my brain said filters) :)

I was actually thinking about the hooks package (my brain said filters) :)

It should work as well. Having useFilter hook inside @wordpress/hooks might be an interesting challenge in terms of explaining the difference between WordPress and React hooks :) However, this is what it is regardless. Just an observation. I think @youknowriad is right.

@adamsilverstein - any thoughts on this topic as you are expert in terms of WordPress hooks :)

@wordpress/hooks seems to be a plain JavaScript package. Also, there's a general vibe that @wordpress/hooks can be used in any other system which may not necessarily use React. So do we have to maintain that backward compatibility?

@desaiuditd It seems to me that the Reusable Block post type label just needs to be changed to "Reusable Block".

Are we sure we want to expose the UI to the risk of custom post types that could have a very, very, long name especially in some languages? We can't predict a CPT name length and CSS techniques like text-overflow: ellipsis; don't seem a good idea to me 🙂

Are we sure we want to expose the UI to the risk of custom post types that could have a very, very, long name especially in some languages?

I think that's a perfectly acceptable risk. Labels are, after all, "official" user-facing names of a CPT. They are arguably expected to be succinct. For instance, the generic label name is the fallback for menu_name, which is a label that needs to fit in WP-Admin's sidebar.

Case in point: the label "A very long Custom Post Type name" still fits, even if not elegantly. It becomes a problem at three lines.

We can't predict a CPT name length and CSS techniques like text-overflow: ellipsis; don't seem a good idea to me

IMO this is the kind of issue that we'd only look at if and when it proves to be an issue.

Related: #20877 (comment) That particular exploration from @dubielzyk brings the Document tab into the menu popover.

@swissspidy @ZebulanStanphill @mcsf I've added the shim to override the post type labels for reusable blocks.

Respective trac ticket to update it in WordPress Core Trac#50755